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IMPROVED TELECOMMUNICATIONS SYSTEMS AND METHODS 

CROSS REFERENCE TO RELATED APPLICATIONS 
This application is a continuation in pare of, and 
claims the benefit of, U.S. Provisional Patent Application No. 
60/046,240, filed May 12, 1997, the complete disclosure of 
which is herein incorporated by reference. 

BACKGROUND OF THE INVENTION 
This invention relates generally to the field of 
telecommunications, and in particular to Operational Support 
Systems and methods for their use. 

Operational Support Systems (OSS) are a broad 
category of systems that support planning, provisioning, 
installation, maintenance, operation, and engineering and 
administration of network elements, networks and services. 
Additionally, OSSs include systems to negotiate orders, and to 
rate and bill for usage of services. 

Factors such' as deregulation, competition, 
consolidation, convergence and globalization are changing the 
5. nature .of the telecommunications industry . The result of 

these factors is that telecommunication companies are finding 
it increasingly more important to reduce costs, deploy 
existing products more quickly, and offer more services to 
maintain and grow market share. The flexibility, scaleability 
0 and usability of OSSs directly influences the ability to offer 
services quickly and cost effectively. 

Many existing service providers, such as RBOCs, find 
that their existing OSSs are too- fragile, constraining, and 
ccstly to meet the demands of a competitive marketplace. 
5 Hence, it would be desirable to provide both new and existing 
service providers with an improved operational support system 
to enable them to offer their services conveniently, quickiy 
and cost effectively. 
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OBJECTS OF THE INVENTION-. • 
OSS users include network providers and managers 
(connectivity providers), network designers and developers, 
retailers, content providers, service providers and managers, 
5 service subscribers (brokers) , service users (consumers) , and 
operators and administrators. It would be desirable if all 
such users could share a common user experience when 
interfacing with an OSS. More particularly, it would be 
desirable to provide the OSS with intelligent components and 

10 data models to integrate heterogeneous elements into, a 

concrete, homogenous, view. . It would further be desirable if 
such interfaces were aware- of* new services , ^ management 
functions, or resources installed into the system. Such 
components should also be able to discover, obtain and display 

15 an editor or viewer associated with the new service, 

management function or resource. It would also be desirable 
to incorporate artificial intelligence to evaluate work in 
progress and offer suggestions to the user to insure that the 
work is complete and accurate. 

20 Further, it would be desirable if tasks performed 

within the OSS were configured to be straightforward, 
consistent, and repeatable. In this way, the learning curve 
for interfacing with the system would :be> greatly reduced. 
Further, the need for systems specific experts would be 

25 reduced, as well as the time to implement a new service, 
management function or resource. 

It is another object of -the invention to provide an 
OSS with a single enterprise data model . Such a model should 
be layered and hierarchial and be configured to support data 

3 0 abstraction and minimize dependency. between layers in the 



model. It would further be desirable, if the data model were 
template based to facilitate introduction of new data models. 
Further, such a configuration should allow for the rapid 
introduction of new -kinds of data models, to provide a single. 



35 



common view of data models, and . eliminate synchronization 
inaccuracies between. users of the data. 



It is still a further object of the invention to 
provide an OSS with. the ability to reflect the service 
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provider's business strategy, policies and standards in work 
flow and business rules. Also, the ability to rapidly change 
and validate work flow and business rules in response to 
changes in strategy, policies and standards should be 
provided. In another aspect, it would be desirable to collect 
metrics and measurements throughout the system. The OSS 
should also support separation and interoperability between 
business domains and authorities. Such features should allow 
the service provider to be differentiated in their marketplace 
as well as' to provide control and accountability.. 

In still a further object, it would be desirable if 
the invention provided- open, standards compliant architecture 
which includes intelligent (domain aware) components that 
discover and utilize services, management functions and data 
models provided by other components. The invention should 
also* support distributed processing and, "plug-and-play " 
scaleability. It would further be desirable if the invention 
provided a layered, open architecture that supports 
scaleability through process and data abstraction, permits 
mult i -vendor solutions, and permits integration of different 
technologies, as well as supporting piece wise replacement of 
legacy systems. In* this way, the invention will allow for 
rapid introduction of new services and; management functions, 
as well as permitting vendor competition. 

SUMMAJ^Y OF THE INVENTION. 
The- invention provides* exemplary systems and methods 
for overcoming- or greatly reducing the drawbacks of prior art 
telecommunication systems, as well as providing solutions to 
the objects of the invention. . In one exemplary embodiment, a 
telecommunication system is provided which is useful in 
connection with at least one network element. The system 
comprises a plurality of platforms, each of which has a 
defined functional xesponsibility . A plurality of components 
are selectively attachable to the platforms. The components 
of each platform are configured to operate together to perform 
various tasks within the functional responsibility of the 
platform. Further, one of the platforms is adapted to be 
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placed in communication with the network element to allow 
configuration information to be transmitted from the platform 
to the network element. In this way, the telecommunication 
system may be arranged in functional layers (according to the 
platforms) , with the platforms functioning as a unifying 
element within each layer to provide common services to its 
components, to orchestrate work between components, as well as 
to provide standards, rules, and principles for component 
granularity and location. In turn, the components are 
provided to perform the actual work within the platform. 

In one particular aspect, a gateway is further 
provided to interconnect at least some of the platforms. The 
gateway includes any electronic interface to place the 
interconnected platforms in communication with other service 
provider systems. In this way, the system of the invention 
may easily interface with the systems of other carriers. In a 
further aspect, mediators are provided to interconnect each of 
the platforms. The mediators include code to translate 
information which is transmitted between platforms.' In this 
way, the "view" of a domain may be translated between the 
platforms. 

Preferably, the defined functional responsibilities 
for the platform' will include customer service management, 
network service management, network management ; network 
element management and the like. One advantage of - the 
invention is that' a variety of components may be selectively 
placed into the platforms. Such components may include, for 
example, network management ' systems, service order management 
systems, order entry systems, monitoring systems, . rating and 
billing systems, inventory systems, work force administration 
systems, rating systems, capacity planning systems, network 
operation systems and the like. Preferably, each platform 
will include a bus to channel information between. each of the 
components in the platform. 

In a' specif ic aspect, one of the platforms comprises 
a network element management platform which is adapted to 
interface with a plurality of network elements, such as STPs, 
SCPs, SSPs and the like. The system will also preferably 
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further include a daca model which is placed in communication 
with at least some of the platforms. The data model includes 
code for providing the state, attributes and behavior of 
telecommunications domain objects. In this way, various 
information regarding telecommunications domain objects will 
be accessible to the components when performing a task. In a 
further aspect, at ■ least one of the platforms will include at 
least one user interface, such as graphically user interfaces 
to allow a user to access the information within the system. 

The invention further provides an exemplary method 
for providing telecommunication services. According to the 
method, a- plurality of platforms are provided which are each 
assigned a functional responsibility. At least one component 
is selectively placed into each of the platforms so that the 

■ component may perform a task within the functional 
responsibility of the platform. In this way, components in 
the platforms translate the services as understood by the 

■ consumer of the service into the information necessary to 
configure a network and network elements to deliver the 
service . 

Each of the platforms is preferably configured to 
provide common services to each of its components to allow the 
components to perform their given tasks , For example, the 
platforms will preferably facilitate work flow between the 
components, to allow the components to cooperate together to 
perform, various tasks within the functional responsibility of 
the platform. Such functional responsibilities may include, 
for example, customer service management, network service 
management, -network management, network element management and 
the like. The platforms will also preferably be configured so 
that they will be able to determine the type of component upon 
placement into a platform. In this way, a variety of 
components may be easily introduced into a platform. 

As one example, the components may be selected to 
provide a local number portability task. The transmitted 
information will then comprise call routing information which 
provisions the network elements. 
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In another aspect of the method, at least some of 
the telecommunications information will preferably be 
translated when transmitted between platforms. 

Telecommunications information which is transmitted to another 
service provider's telecommunication system will preferably 
also be translated. Conversely, telecommunications 
information received from another service provider will 
preferably be translated before being transmitted to the 
platforms. 

Conveniently, information from the components and 
business rules associated with the operation of the components 
may be accessed with a graphical user interface." In still 
another aspect, the state, behavior and usage information 
relating to telecommunications domain objects will preferably 
be transmitted to at least one of the 'platforms to assist the 
components in performing a task. Such information may 
include, for example, network element requirements, facilities 
requirements, work force requirements, and the like that are 
needed to accomplish a task. 

In still yet another embodiment, an exemplary method 
is recited for providing telecommunications services. 
According to the method, a telecommunication service is 
ordered and entered into an order entry component that is 
interfaced with a service management (customer facing) 
platform. A data model is queried through the service 
management (customer facing) platform to determine if the 
product is available for order. If available; information 
relating to the order is transmitted to a service management 
(network facing) platform having an order management 
component. The data model is again queried through the 
service management (network facing) platform to determine the 
particular resources that will be required to service the 
order. Information relating to the order is then transmitted 
to a network management platform to determine if the 
particular resources are in fact available to service the 
order. Finally, information relating to the order is 
transmitted to network element management platform to 
provision or configure the service on a network element. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 illustrates a conceptual model of an 
exemplary telecommunications system according to the 
invention. 

Fig. 2 illustrates a schematic view of one 
embodiment of an exemplary telecommunications system according 
to the invention. 

Figs. 3A-3D illustrate four types of components that 
may be coupled to the telecommunications systems of Figs. 4-6. 

Fig. 4 is a schematic view of an embodiment of a 
telecommunications system illustrating various products and 
services which are coupled to the system according to the 
invention . 

Fig. 5 is a detailed view of a service management 
(customer facing) platform and a service management (network 
facing) , plat form of a telecommunications system according to 

the inyention. 

Fig. 6 is a detailed view of a service management 
(customer facing) platform and a service management (network 
facing) platform of a telecommunications system to which a 
local service request management product is coupled according 
to the invention. 

DETAILED DESCRIPTION OF THE SPECIFIC EMBODIMENTS 

The invention provides exemplary telecommunication 
systems. and methods for their use. The systems comprise an 
.OSS having layers of platforms and components that may be 
selectively interfaced with each of the platforms to perform 
various tasks. The OSS of the invention is based on 
telecommunication management network (TMN) architecture that 
organizes service and management functions into layers. Each 
layer of the OSS abstracts and comprehends the use of the 
services and management functions available in the next lower 
level, enabling scaleability and flexibility by promoting data 
and process abstraction. 

According to the invention, OSS applications 
comprise collections of components that provide services and' 
management functions necessary to automate telecommunications 
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business processes. The components are organized into the 
layers of the TMN architecture and collaborate to perform a 
kind of task. Further, such applications are typically not 
independent, i.e., the components of an application may rely 
on other services and management functions which in turn are 
provided by other components within the same- layer. To 
facilitate such cooperation, the OSS of the invention includes 
a management platform within each layer to establish interface 
and functionality standards, to apply business rules and 
logic, and to provide common services to all components within 
a layer. 

The OSS of the invention further includes an 
enterprise data model that maintains information and resource 
models (products, services, equipment and the like) that are 
accessible by multiple OSS applications or decision support 
systems. The enterprise data model is hierarchial in the same 
manner as the TMN architecture such that the data models 
available to components within a level are at the appropriate 
level of abstraction. ' The OSS of the invention further 
includes integration with work flow managers to provide a 
flexible mechanism to define business processes. Optionally, 
integrated user interfaces may be employed to tie diverse 
information into a common presentation for a user. 

A conceptual model of an OSS -8 is illustrated in 
Fig. 1. As shown, the various platforms or software buses are 
arranged into layers which conform- generally to the TMN 
layers", i.e. a service management layer (customer/retail) , a 
service management layer (network/ wholesale) > a network 
management layer, and an element management layer. The 
various platforms may communicate with each other through a 
mediator. Further, the platforms may communicate with 
external systems, including other service provider systems, 
through adapter components, such as fax, e-mail, EDI, and the 
like., 

The platforms are configured such that various OSS 
application components and/or common service components may be 
coupled to the platforms. Information from each of these 
components may be accessed and/or transferred through the 
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platforms and mediators. Further, each platform includes an 
enterprise data model. This enterprise data model includes 
information model service components and domain model 
components. The service components can include databases for 
storing data received or extracted from other components in a 
relational representation, report tools and facilities, and 
the like. The domain model components include services that 
model entities involved in telecommunication business 
processes for operations, planning and engineering, service 
provisioning, and customer care and billing. These entities, 
which are presented by objects, model both state (attributes) 
and behavior, and can include, for example, customer, product, 
service, order and network elements. 

As previously mentioned, the platforms provide 
access to common software services, for applications through a 
software bus, using Application Programming Interfaces (APIs) , 
to facilitate efficient development and integration of OSS 
application components for service providers into a common 
.run-time environment. This is accomplished by providing easy 
access to reusable common services that allow application 
development efforts to focus on improved functionality rather 
than the underlying common processes of such applications. 
The published APIs -for the common software seirvices also 
facilitate adaptation of existing applications to this common 
run-time environment which, in. conjunction with the enterprise 
data model, provides consolidated .information sharing and 
reporting with various products, including products offered by 
other application developers (vendors) . 

- The software bus thus enable various OSS application 
components, which are appropriately, compliant with published 
standards and APIs, to access and utilize common software 
service components, as well as -to utilize the enterprise data 
model to retrieve information from and share information with 
other applications within the OSS. Further, such information 
may be received from or shared with other OSS's and external 
applications. The software bus preferably enables layering of 
software applications in accordance with the ITU-T TMN 
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architectural modal and utilizes a widely accepted or industry 
standard Object Request Broker, e.g. CORBA-compliant . 

Referring now to Fig.. 2, an exemplary embodiment of 
an OSS 10 will be described. OSS 10 comprises a- plurality of 
platforms, including a service management (customer facing) 
platform 12, a service management (network facing) platform 
14, a network management platform 16, and a network element 
management platform 18. Interfaced with the various platforms 
are different components 20 which are responsible for 
performing various tasks as described in greater, detail 
hereinafter. 

The various platforms are the unifying element 
within each layer of OSS 10. As such, the platforms comprise 
various software services, middleware, frameworks and 
standards. Each of the platforms has a defined functional 
responsibility. For example, platform 12 is. responsible for 
customer facing service management. Platform 14 is 
responsible for network facing service management, while 
platform 18 is responsible for network management . Finally, 
platform 18 is responsible for network element management. A 
plurality of network element management systems 22 are 
interfaced with platform 18 to assist in provisioning or 
configuring various network elements . 24 . . 

The specific functional responsibilities of the 
platforms may include, for example, the collection and 
evaluation of. metrics and measurements, and the collection and 
evaluation of alarms., status, and error information. The 
platforms may further provide access to components 2 0 and to 
resources from an enterprise data model 26 at the platform's 
level. The platforms further encapsulate and enforce business 
rules, e.g., validation and verification, applicable to a 
platforms level. The platforms further provide communication 
(transport) between components 20 and data model 26 at the 
platform's level. Further, the platforms enforce layered 
architectural principals by defining standards for the 
construction of components 20 for each layer of OSS 10. The 
platforms further provide APIs, protocol stacks, frameworks, 
and the like. The platforms are also employed to produce 
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Standards -for implementation, integration and migration of 
components 20 and data model 26 into the platforms. 

The platforms are further configured to provide a 
variety of common services including: security, persistence, 
transaction management, naming and directory services, 
underlying protocol transparency, alternate, messaging routing, 
resource discovery,' and the like. Such platforms further 
provide standard- interfaces or gateways to work flow 
management and to data model 26. Such plat forms ' also provide 
access to services and resources for presentation, i.e., user 
interfaces . 

Another specific function of the platforms is to 
provide for work flow management. Work flow provides a 
mechanism to orchestrate a wide variety of actions to 
accomplish a task. This is particularly important when a 
situation requires human intervention. Hence, work flow 
provides a mechanism to hand-off and track a task assigned to 
an individual or organization. Additionally, work flow also 
provides a mechanism for defining and implementing business 
processes, particularly in regard to -handling exception cases. 

Accessible through each platform, each component 2 0 
will preferably have an API that permits integration with a 
work flow manager. -In instances where work flow management is 
not required;- the platform will - preferably orchestrate work in 
accordance with imbedded rules. 

The application areas' provide an organizing 
principle for the development and integration of components 
that perform a kind of task. Components within each 
application do not necessarily function in isolation, rather 
they may rely on services and management function provided by 
other components within the layer. Such application areas 
preferably include operations, planning and engineering, 
service provisioning, and customer care and billing. The 
operations applications can include, for example. Advanced 
Intelligent Network (AIN) services, human resources, payroll, 
financials, network operations and fault management, field 
service and repair, security and work force management, and 
the like. 
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Planning and engineering is focused on network: 
design, decision support, product planning and development, 
and the like. Some areas ofi.^ service provisioning include 
configuration management, inventory management, provisioning, 
service activation, service order processing and the^ like. 
Finally, customer care and billing includes applications for 
billing, customer support and service, pricing, rating, sales 
and marketing, and the like. 

The following table lists examples of applications 
within each category mapped to the TMN layers. 

table" 1 " ' 





Operations 


Planning and 
Engineering 


Service 
Provisioning 


Customer 
Care and 
Billing 


BML 








• Chum Managemenl 

• Demand forecasting 


SML 


• Product planning 


• Producl design 

• Capacity planmng 


Order entry - 

• Order management 


^Wholesale and retail 
rating and billing 


NML 


• Worti force admintstration 

• FauH managemenl 


• Serkflce design 

* Circuit desiqn 


• Physical and virtual 
inventory manaqemeni 


• Usage collectton and 
mediation 


EML 


• Monitonng 




• LNP NEMS 




NEL 











A wide variety of components 2 0 may be provided to 
accomplish the various tasks required to provide the OSS 
services. Exemplary components which may be used with the 
invention include: network management systems, service order 
management systems, order entry systems, monitoring systems, 
billing systems, invesntory management systems, work force 
administration systems, rating systems, capacity planning 
systems, network operations systems, service provisioning 
management systems, and the like. Exemplary network 
management systems, service order management systems and order 
entry systems are described in copending U.S. Provisional 
Applications Serial Nos . 60/033,421, 60/033,422 and 
60/033,423, all filed on December 24, 1996, and UiS, Patent 
Application Serial" Nos . 08/907,323, filed August 6, 1997 and 
08/906,751, filed August 6, 1997. The complete disclosures of 
all these applications are herein incorporated by reference. 
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Enterprise data model 26 provides a single (logical) 
repository of shared data and resource models used in OSS 
applications and decision support systems. The shared data 
and resource models are preferably hierarchial in the same 
fashion as the TMN layers providing the appropriate level of 
abstraction for components within a layer. The following 
table illustrates the kinds of models that may be present 
within each layer of the TMN architecture. 



TABLE 2 





Models 


BML 


• Markets, mantel segments 


SML 


• Producis (available services) 


NML 


• Service Elements 

• Equtpment 

• Outside Ptan: 


EML. 


• NetwoTX etemeni {mirror) 


NEL 





The enterprise data model is configured to provide 
" the current state; behavior and usage constraints. Such 
information is made available to the components 20 to perform 
their various, tasks. 

To enhance useability, selective user interfaces 28 
may be provided. Due to the nature of the OSS architecture, a 
task or a similar set of tasks may involve multiple components 
and resources. Interface 2 8 provides a common framework to 
unite the presentations of multiple components and to data 
model 26, providing a common look and feel through consistent 
presentation, navigation and help. 

Positioned between some of the platforms is a 
mediator 30 which includes code to translate information which 
is transmitted between the platforms. In this way, a 
particular "view" of a domain may be translated between the 
various platforms. OSS 10 further includes a gateway 32 which 
interconnects other service provider systems, such as system _ 
34, with platform 12, and acts as a mediator between platforms 
12 and 14. 
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An exemplary method for employing OSS 10 to provide 
various telecommunications services will now be described. In 
a typical application, a customer will order -a 
telecommunication service which will be entered into one of 
5 components 20 in platform 12. Such a component will 

preferably be an order entry component which is employed to 
query data model 26 through platform'12 to determine of the 
ordered product is available for order. If available, 
information relating to the order is then transmitted to 

10 platform 14, which will preferably include: an order management 
component. The order management component will then query 
data model 26 through platform 14 to determine the particular 
resources that will be required to service the order. Upon 
determining this information, the information will be 

15 transmitted and translated to network management platform 16 
via mediator 30. Platform 16 will include various components 
which are employed to determine if the particular resources 
are actually available to fulfill the order and the. steps 
necessary to fulfill the order. For example, * .the components 

2 0 on platform 16 may comprise a service activation component, an 

inventory component and a work force component . !£ everything 
is in order, the steps determined to fulfill the order are 
executed and information relating to the- order is then 
transmitted to network element management ^platform 18 via 

25 mediator 30 so that the service may be delivered or configured 
■ ' by network elements 24 . 

Hence, OSS 10 provides users with enhanced flexibility by 
allowing a wide variety of components to be inserted into the 
various platforms in order to accommodate various services 

30 provided by service carriers. Over time, as new services are 
added or old services are replaced, OSS 10 is able to easily 
accommodate such changes by simply allowing different 
components and objects to be replaced. Each of the platforms 
will preferably include middleware that will be able to 

3 5 determine the type of added component so that it may easily be 

configured into the system. Hence, both scaleability and 
flexibility are provided to allow service providers to 
effectively compete in the telecommunications market. 
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Referring now to Figs, 3A-3D, various components 
which may be coupled to the telecommunications systems of 
Figs. 4-6 will be described. Shown in Fig. 3A is an OSS 
application component 40. Figs. 3B-3D illustrate an adapter 
42, a service or facility 44, and a domain object resource 
model 46, respectively. OSS application component 40 
represents a software application component which implements 
one or more activities of a business process. Adapter 42 is a 
component that allows an OSS to communicate externally, such 
as with another service provider's system. For example, 
adapter 42 may support protocols such as facsimile, e-mail, 
EDI, FTP; CMIP, and the like. Service or facility component 
44 is a component that provides functionality common to 
application components. Components 44 are common so that they 
can be shared by different products. Domain object resource 
models* 46 are services which model entities involved in 
.telecommunication business processes for operations, planning 
and engineering, service provisioning, customer care and 
billing, and the like. These entities, represented by 
objects,- model both state (attributes) and behavior. 
Exemplary domain object resource models 46 include customer, 
product, service, order,, and network elements. 

Shown in Fig 4. is one particular embodiment of an 
.OSS 50. and is- included to illustrate various OSS application 
components .which may be coupled to the various platforms. For 
example, an order entry component- 52. is ^a component which 
-facilitates :the entering of various order information into the 
system as .described • in greater .detail hereinafter. A service 
management layer (network facing) platform. 54 includes the 
following components: .a local service management .component 
56, an order .management component 58, a mutual compensation 
rater component 60, a mutual compensation biller component 62 
and a. mutual compensation reconciliation component 64. The 
order entry component 52. is- coupled to a service management 
layer (customer facing) platform 53. Exemplary uses of these 
components are . described hereinafter. 

- Coupled to a. network management layer platform 6 6 i's 
a service activation component 68, an inventory management 



wo 98/52321 



PCT/US98/09697 



16 

component 70, a workTorce management component 72 and a usage 
mediation component 74, Finally, coupled to an element 
management layer platform 76 is a usage collection component 
78. The various components coupled to platforms 53, 54, 66 
and 76 are particularly useful in facilitating a local service 
request and for the exchange of billing information between 
different service providers as described in greater detail 
hereinafter. As such, it will be appreciated that the various 
components coupled to OSS 50 are merely representative of the 
various components may be coupled to the 'OSS to provide 
various services to customers. 

OSS 50 further includes various- mediators- which 
provide access control/ translation and filtering of data 
between the various platforms. An output manager 80 is 
further provided and is coupled to various adapters- which 
allow for external communication. Output manager 80 is 
similar to the Inter-SP Gateway of Fig. 1 and gateway 32 of 
Fig. 2. Exemplary adapters which may be coupled to output 
manager 80 include an EDI- adaptor 82, an e-mail :adaptor 84, a 
fax adaptor 86,' a FTP adaptor 88, as well as other adapters, 
such as adaptor 90 which are useful in transferring data from 
OSS 50 to another OSS. 

Coupled to each of the platforms via. .an information 
bus are one or more domain object -resource models,.. For 
example, coupled to platform 53 is a customer model 82, a 
product model 84 and an order model 86. Customer model 82 is 
a service that is employed to store information associated 
with a customer and provides a set of screens on a user 
interface computer 87. Such screens, in turn, are employed to 
solicit and record information regarding a customer. Product 
model 84 includes information on the various 

telecommunications products that a customer may order. Order 
model 86 cooperates with customer model. 82 and product model 
84 and is employed to produce a series of screens on computer 
* 87 which solicit and record information necessary to fulfill a 
particular order for a customer. 

Coupled to platform 54 is a service, provider model ' 
88, and order fulfillment model 90, a service model 92 and a 
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local service request' model 94. Service provider model 88 
includes information regarding which services are offered by 
which service providers and typically includes the 
intraconnection agreements between service providers. Service 
model 92 contains information on the services that comprise 
the products, as well as the tasks and dependencies that are 
necessary to deliver the service. Order fulfillment model 90 
is created by order management component 58 to contain a list 
of tasks and dependencies necessary to fulfill an order. 
Order - management component 58 uses information from order 
fulfillment model 90 and appropriate service models 92 to 
create this list. Local service request model 94 is employed 
to store information from customer model 82, order model 86, 
service provider model 88 and service model 92 so that a local 
service request may be sent to another service provider. 

Coupled to network management platform 6 6 is a 
network topology model 96, a network element model 98, a 
service elements model 100 > a workforce model 102, a physical 
inventory model 104 and a virtual inventory model 106. 
Physical- inventory model 104 represents a collections of items 
that comprise the physical plant (e.g., cable pairs, 
communication cards and the like).. Virtual inventory model 
106 includes a collection of virtual resources available 
within the network (e .g . , bandwidth)-. Resource models 96-106 
work in cooperation with components 68-74 on network 
management layer .:platform.- 66 to , assist in fulfilling a 
particular order. For instance,- service activation component 
68 is provided to assist in- configuring or provisioning one or 
more network elements 108 to provide the service requested by 
the customer. Inventory management component 70 identifies 
the resources, physical and virtual, that are necessary to 
deliver the requested services and adjust the inventory levels 
appropriately. Once the resources have been identified, this 
may spawn additional tasks to order replacement stock, notify 
facilities planning of band width exhaustion and the like. 
Work force management component- 72 dispatches technicians to 
install hardware, lay cable or otherwise modify the physical 
plant. Usage mediation component 74 is employed to normalize 
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call records received from various network elements into a 
common format . • 

Resource models 96-106 include data that may be 
accessed by components 68-74. For example, network topology 
model 96 includes a description of the interconnection of 
network elements and their location. Network element model 98 
includes information on the actual network elements 98 that 
are available for use. Service elements 100 include 
information on the elements that comprise a service. A 
service element may be reused in one or more services. 
Workforce model 102 includes information on the needed and 
available technicians which will install or modify the 
hardware or physical plant to deliver the product. Physical 
inventory model 106 includes a list of available inventory as 
well as required inventory for a particular product. Virtual 
inventory model 106 includes a list of available virtual 
inventory as well as the needed inventory required- to 
implement a given product . 

Coupled to element management layer platform 76 is a 
functional entity model 110. Functional entity model 110 
includes detailed information necessary to provision a service 
element on a particular network element. In turn, such 
information is used -by the network element management 
components to provision a network element. Usage /collection 
component 78 collects call records from network elements. 

Referring now to Fig. 5, one particular arrangement 
of an OSS 120 will be described. For convenience of 
illustration, ' only a' service management layer (customer 
facing) software platform or * bus 122 and a service management 
layer (network facing) software bus or platform 124 are shown. 
It will be appreciated that' a network management layer 
software bus or platform and an element management layer 
software bus or platform which are similar to those previously 
described herein -will be coupled to OSS 120 by a mediator in a 
manner similar to that previously described. OSS 12 0 includes 
an output manager 126 to which various adapters may be coupled 
similar to the- embodiment previously described in Fig. 4. 
Also similar to' the embodiment of Fig. 4, a variety of domain 
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object -resource models are coupled to the various software 
buses. Further, various components may be coupled to software 
buses 122 and 124 similar to the other embodiments described 
herein. Each of the components preferably includes a server 
to facilitate the transfer of information between the 
component and the software bus as is known in the art. 
Conveniently, a* Legacy adaptor 128 may be coupled to software 
buses 122 and 124 to provide communication to external 
applications 130. For example, such - external applications may 
include service order entry systems, trunk group assignment 
systems, such as SOAC and TIRKS,, available from Bellcore. 

Coupled to layers 122 and 124 are a variety of 
services or facilities. For example, a user interface tool 
132 provides various tools and facilities to support the 
creation and running of human interfaces 134, such as GUIs, 
for various OSS applications. User interface tools 132 
preferably include client service standards and models which 
provide documentation of standards and conventions for 
creating and partitioning client-server applications. For 
example, these standards may include detailed descriptions of 
how thin a client should be, .including descriptions of what 
function should normally be performed in the server and what 
functions- in the client. User interface tools 132 preferably 
also include look and feel standards on models which provide 
documentation of look and • feel, standards , including GUI style 
-guides. They may also include code frameworks that implement 
the standards, -or support easy, implementation. User interface 
tools 132 may further include tools and- facilities to support 
the integration of test tools, and for testing GUIs. Tools 
and facilities may also be included to support integration of 
on-line -help and documentation into application GUIs. 
Further, tools may be provided to support printing of any GUI 
screen, as displayed, along with any data on the screen. 

A distribution service 136 includes a directory 
service to provide the capability to locate services, 
facilities and other components, either by name or by services 
offered. As one example, CORBA Trader and CORBA Naming 
services provide directory services -and may be used with the 
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invention* Distribution service 136 f urther'allows for the 
determination of what services are wanted based on incomplete 
information about that service . For example, it may- 
accomplished by allowing access to the CORBA Interface 
5 Repository. 

A security service 138 is further provided to verify 
the identity of a user by' comparing a- user ID and password 
with previously stored account information. The security 
service further uses information provided by -an account 
10 management service (described hereinafter) *to verify that a 

user has the appropriate privileges to access an application. 
Security service 138 may be based on existing CORBA security 
products . 

Transaction management service 140 synchronizes a 

15 unit of work, called a transaction which involves multiple 
components (applications, facilities or services) . In this 
way, all actions against individual componentis must be 
successful in order for the transaction to be successful. Any 
action that fails will cause all actions to be rolled back to 

20 restore to a previously known state. Transaction management 

service 14 0 may be based on a CORBA Object Transaction Service 
product , ' ' 

A business process management service 142 includes 
tools to aid in the definition^ modification, : execution and 

25 tracking of work processes. It also allows a user to define 
the order in -which work will be done in response to given 
inputs or events. It further requires that- the work being 
performed is divided' into units that can be assembled in 
workflow. This service may be based on Workflow Management 

3 0 Consortium (WfMC) standards. 

Further coupled to layers 122 and 124 is a process 
management service 144 which includes tools and other 
facilities to support the administration of the pieces of the 
processes, data and other parts of individual applications. 

3 5 For example, it may include facilities to start, stop, restart 
and otherwise manage the processes that make up an 
application. It also includes the ability to configure those 
processes, including the restart characteristics. Process 
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management service 144 further includes facilities to monitor 
aspects of an application, including the status of the 
processes. It may further extend the process management 
capabilities listed above to distributed applications, where 
the processes and data of an application are distributed 
across the network. 

A tunable management service 146 is included to 
provide facilities, including GUI, to browse tunables and sets 
of tunable values used to configure applications. It also 
includes facilities to effect updates at run time. 

A deployment service 14 8 is provided to support 
aspects of the deployment process. For example, this may 
cover deployment of OSS applications (i.e., applications built 
on the OSS framework) to the . purchasers of those applications. 
However, the same tools are also applicable to the deployment 
of releases of the OSS itself. For instance, deployment 
service 148 may be configured tp support the initial 
installation of a new product. by providing tools which aid in 
the installation process, beyond what is provided by standard 
UNIX tools. It also allows for the installation of upgraded 
versions of existing products. Deployment service 148 further 
provides support for packaging of releases, as well as in 
providing tools to aid in creation of patch releases. A patch 
may not contain the entire system, but only patches those few 
files that need to be patched to address a specific problem. 
Further, deployment service 14 8 may include tools to aid in 
organizing and managing multiple simultaneous releases or 
patches. It may further include tools to support and automate 
aspects of the distribution of releases for patches for 
applications. 

An exception handling service 150 provides generic 
services to deal with exceptional conditions encountered at 
run-time. . Although not all exceptional conditions are 
necessarily errors, this preferably includes the capability to 
define levels of error criticality. Exception handling 
service 150 may provide access to the generic log management 
capabilities (described hereinafter) to manage the error log. 
It may further include an object model for exceptions. By 
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defining a hierarchy 'of exiting except ion - class for use by OSS 
applications, functionality is allowed to be encapsulated and 
reused. Further, exception handling service 150 includes an 
object model for errors. 

A local time support service 152 includes tools to 
support the coordination of data and processes across multiple 
time zones. For example, this might include the ability for a 
GUI to display the local" time of a time-stamp on a .data object 
regardless of where the time-stamp was recorded. 

A log management service 154 is a generic feature 
that provides tools and facilities to manage any log 
maintained by the system. For example, it may provide a 
process of initially recording events for later use. It may 
also provide tools, typically GUI-based, to allow a user to 
scan through a section of a specified log, searching for 
events that match a desired set of criteria. Further, an 
interface may be provided to the reporting^ subsystem that 
allows selected entries from the log to be output in a 
formatted way and redirected to some output device. Log 
management service 154 further includes tools and facilities 
for organizing the data in the log according to a user- 
specified set of criteria. * Further, log management service 
154 may be employed to send a formatted and human readable 
version of a log to different devices/ locations .: : For example, 
this might support redirecting the formatted log to the 
terminal, a printer, a file, e-mail, fax or the like. 

A login/logout service provides tools, including GUI 
and access to authentication information, to support logging 
in and logging out of users of ■ the OSS applications. An 
account management service 158 provides administrative 
services for managing users of OSS applications. The service 
includes functions for creating, modifying, retrieving and 
deleting user accounts. It also provides for the 
administration of both authentication information e.g., user- 
ID and password) and authorization information, i.e., what the 
user is allowed to do". Account management service 158 further 
provides functions for creating, modifying, retrieving and 
deleting user group definitions. 
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A trace log service 160 provides tools and 
facilities to support debugging and tracing application code. 
It also includes the ability to dynamically alter trace level 
at run- time . 

A report management service 162- provides tools and 
facilities to support the creation, scheduling and management 
of reports. For example, it may include a set of standard 
queries, or reports, for reporting on data associated with 
other OSS services and facilities. As one example, if a user 
administration function is provided, then the standard reports 
may include user, user group ^ and related reports. Report 
management service 162 further includes tools and facilities 
to allow the user to define- their own reports, and then 
schedule the reports, redirect output and otherwise treat the 
reports as additional standard reports. It further includes 
tools to. support scheduling of reports to be run at a 
specified time, at a specified frequency, with specified 
selection and sort criteria. The tools also allow changing of 
the scheduled attributes of existing schedule reports, as well 
as cancellation of those reports. It further provides an 
interface to generic output redirection tools^ to support 
redirection of report output to a selected output device, such 
as -a fax, system file, e-mail, a named printer, the user 
screen or the like. 

• A data store management service 163 maps data 
received or extracted from other -components into a relational 
representation. It further encapsulates and presents a 
standard interface to allow access to the relational data. 

OSS 120- further includes an operational (Ops) data 
store 164 which -is a temporary relational store to facilitate 
integration of existing (non OSS 120 compliant) systems. A 
data warehouse 166 is a long-term relational store that is 
optimized for reporting and decision support. 

As mentioned above, output manager 126 is 
responsible for managing the process of transferring 
information to and from another service provider or trading 
partner. The adapters convert the information into required 
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formats (e.g., EDI, fax, e-mail and the like -as specified by 
various standard bodies such as OBF and ECIC) . 

Referring now to Fig. 6, a particular implementation 
of OSS 120 to support a scenario where a new customer requests 
a product and where another service provider provides one or 
more services that comprise the product will be described. 
For convenience of discussion, the elements in Fig. 6 which 
are essentially identical to those in Figi 5 will use the same 
referenced numerals. It will further be- appreciated that the 
particular components included within Fig". 6 are merely 
representative of one set of components that may be. coupled to 
the OSS system, and that other components, including those 
previously described in connection with Fig. 4 , may also be 
coupled to the various layers to provide other services. 

In the following scenario, a new customer requests a 
telecommunications retail product. Such a product is 
typically a group of packaged services such as caller ID, call 
forwarding, and the like. Such services are typically bundled 
together by service providers into the telecommunications 
retail product. The particular service is described by a set 
of service elements which are independent of network element. 
A service element in turn is described by a set of functional 
elements which are network elements specific. In the 
scenario, another service provider provides one or more of the 
services that comprise the telecommunications retail product, 
thereby requiring the generation and transmittal of a local 
service request (LSR) to fulfill the order. 

To request the product, the customer contacts a 
customer service representative (CSR) . In turn, the CSR logs 
into an order entry component or application 170. The login 
screen seen by the CSR (and provided by login/ logout service 
156) collects the u^er ID and password from the. CSR and passes 
the information to security service 138. In turn, security 
service-' 13 8 authenticates the identity of the CSR' by comparing 
the user ID and password with those stored in a user account 
resource model^ 172. Once verified, security service 138 
checks an access control list resource model 174 to authorizecl 
the CSR' s access to order entry component 170.. If 



wo 98/52321 



PCT/US98/09697 



25 

authentication and authorization is successful, security 
service 138 notifies login/logout service 154 that the CSR is 
an approved user of order entry component 170. Otherwise, 
security service 138 notifies login/logout service 156 to deny 
che CSR access to the application. In this scenario, the CSR 
is an approved user of order entry component 170. Therefore, 
login/logout service 156 passes control to order entry 
component 170. In turn, order entry component 170 presents 
its main screen via terminal 171 to the CSR. 

Once logged in, the customer may contact the CSR to 
request a telecommunications retail product. The CSR 
determines that the customer is new, and uses the user 
interface provided by order entry component 170 to create a 
new instance of the customer model 82. In turn, the customer 
model 82 presents a series of screens to the CSR to solicit 
and record information from the customer. 

To create an order, the CSR describes the available 
telecommunications retail products to the customer from 
descriptive information presented to the CSR by product model 
84. The customer then selects a desired telecommunications 
retail product. The. CSR selects the "take order" process from 
the user interface provided by order entry component 170. 
Order entry component -170 then -creates an instance of order 
model 86 to hold the association between Xhe customer and the 
selected product. Order model -86 -presents a series of screens 
(derived .from customer model 82 -and product model 84) to the 
CSR to solicit and record information necessary to fulfill the 
order from the customer. The products available to the 
customer is. a function of the services that are available at 
the central office serving the delivery location. 

Order entry component- 170 then passes the completed 
order model 86 to an order management component 176. Order 
management component 176, using the service models 92 that 
comprise the telecommunications retail product,, decompose the 
order into a- set of tasks and dependencies necessary to 
fulfill the order and uses this information to create an 
instance of the order fulfillment model 90 (which also 
includes an association with the originating order model 86) . 
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For the purposes of tTiis scenario, another service provider 
provides one of the services to be delivered as part of the 
product. Although not described in reference to this 
scenario, it will be appreciated that other tasks will be 
necessary to fulfill the order, including service activation 
(provisioning) , inventory management and work force management 
as previously described. 

Order management component 176 passes order 
fulfillment model 90 to business process management service 
142 to orchestrate the completion of the tasks. Business 
process management service 142 initiates tasks' on various 
other applications and components, coordinating the work in 
accordance with the dependencies. As mentioned above, one 
task is to request another service provider to deliver a 
service to the customer. This task is passed to local service 
request management component 178, which, in turn, creates an 
instance of the local service request model 94 and populates 
the model with information from the customer model 82, order 
model 86, service provider model 92 (which contains 
interconnection agreement information) and the appropriate 
service model 92 . Local service request management component 
178 passes the local service request model 94 and service 
provider model 88 to output manager 126 via a mediator 180. 

Output manager 126, using rules provided by service 
provider model 88, translates the local service request model 
94 into the LSR format required by the service provider, and 
manages delivery of the LSR through the appropriate 
interconnection adaptor (e.g., the EDI adaptor). In this 
manner, a LSR may be sent to another service provider to 
provide at least a portion of the service to the customer in a 
manner similar to that described in copending U.S Application 
Serial No. 60/068,166, previously incorporated by reference. 

Because various services will be provided by other 
service providers, a need will exist for exchanging billing 
information between the various service providers. Various 
components which may be used to implement a system for 
exchanging billing information are illustrated in Fig. 4. In 
particular, OSS 50 utilizes usage collection component 78, 
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usage mediation component 74, mutual compensation rater 60, 
mutual compensation biller 62, and mutual compensation 
reconciliation component 64, among others, to exchange billing 
information with one or more OSSs . As described in greater 
detail hereinafter, usage collection component 78 stores call 
records, such as Automated Message Accounting (AMA) records, 
from the network elements. Usage mediation component 74 
utilizes the raw data in the call records to create normalized 
call record objects. Mutual compensation rater 60 associates 
a fee structure with a call record. Mutual compensation 
biller. 62 is employed to apply volume discounts, calculate 
taxes, and the like on an invoice basis to provide invoices 
for each account. Finally, mutual compensation reconciliation 
component 64 is employed to compare an incoming invoice 
received from another service provider via output manager 80, 
and an outgoing invoice to determine the financial obligations 
of each service provider. 

Still referring to Fig. 4, an exemplary method for 
processing mutual compensation billing information will be 
described. For convenience of discussion, the service 
provider operating OSS 50 will be referred to as service 
provider A (SPA) . Typically, SPA will bill another service 
provider,, referred to as service provider B (SPB) , for 
termination of calls originated by SPB's customers. To do so, 
SPB produces a record of every' call they^ either originate or 
terminate. Each of these records has sufficient routing 
information to determine which originated calls were 
terminated by SPA. Similarly, SPA has the same information as 
regards to SPB. 

The method begins with the input of the call records 
from SPA'.s switches into usage collection component 78. This 
information can be automatically downloaded via an X.2 5 OSS 
connection or can be manually loaded via switch tapes. Usage 
collection component 78 continues to load the data provided by 
SPB to validate their invoice, typically provided in summary 
format via switch tape, or electronically via output manager 
80. 
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Usage mediation component 74 retrieves the raw data 
from usage collection component 78 through a mediator. Usage 
mediation component 74 creates call record objects out of the 
individual call records. Each of these call record objects is 
then stored in Ops data store 164 (see Fig. 5) . 

A user then logs in through user interface 87 and 
completes the process of identification and authorization to 
allow the user to use the billing system as described in 
connection with the previous scenario. Once logged in, the 
user begins the billing- application and enters SPB as the 
billing/billed entity. 

Mutual compensation rater 60 and mutual compensation 
biller 62 retrieve the accounts receivable portion of the 
interconnection agreement for SPB from service provider model 
88. Components 60 and 62 load the relevant rating 
information, volume discounts, and the like from service 
provider model 88, and access Ops data store 164 (see Fig. 5) 
to collect all records that represent terminated calls that 
were originated by SPB. Components 60 and 62 apply the rating 
information to the call records and create an electronic 
invoice to be paid by SPB. 

Mutual compensation rater 60 and mutual compensation 
biller 62 further retrieve the accounts payable portion of the 
interconnection agreement for SPB from service provider model 
88. Components 60 and 62 load the relevant rating 
information, volume discount, and the like, and access Ops 
data store 164 to collect all records that represent 
originated calls, that were terminated by SPB. Components 60 
and 62 apply the rating information to the call records and 
create an electronic invoice to be paid to SPB. 

Mutual compensation reconciliation component 64 then 
compares the two invoices and determines which service 
provider owes more. The service provider which owes more will 
then be credited the amount owed to it and component 64 
creates a bill for the remainder. This bill is forwarded to 
an accounts receivable or accounts payable portion of the 
service provider's accounting system as appropriate. 
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The invention has now been described in detail for 
purposes of clarity of understanding. However, it will be 
appreciated that certain changes and modifications may be 
practiced within the scope of the appended claims. 
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WHAT IS CLAIMED IS : ' 

1. A telecommunications system for use with at 
least one network element, the system comprising: 

a plurality of platforms, each platform having a 
defined functional responsibility; 

a plurality of components selectively attachable to 
the platforms, wherein the components of each platform operate 
together to perform various tasks within the functional 
responsibility of the platform, and wherein one of the 
platforms is adapted to be placed in communication with the 
network element to allow configuration information to be. 
transmitted from the platform to the network element. 

2. A system as in claim' 1, further comprising a 
gateway interconnecting at least some of the platforms, 
wherein the gateway includes an electronic interface to place 
the interconnected platforms in communication with other- 
service provider systems. 

3. A system as in claim 1, further comprising 
mediators interconnecting each of the platforms, wherein the 
mediators include code to translate information which is 
transmitted between platforms. 

'4. A system as in claim 1, wherein the defined 
functional responsibilities are selected from the group 
consisting of service management (customer 'facing) , service 
management (network facing) , network management, and network 
element management . 

5. A system as in claim 1, wherein the components 
are selected from the group of components consisting of 
network management systems, service order management systems, 
order entry systems, monitoring systems, billing systems, 
inventory systems, work force administration systems, rating 
systems, capacity planning systems, and network operations 
systems. 
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6. A system as in claim 1, wherein each platform 
includes a bus to channel information between each of the 
components . 

7. A system as in claim 1, wherein one of the 
platforms comprises a network element manager platform which 
is adapted to interface with a plurality of network elements. 

8. A system as in claim 7, wherein the network 
elements are selected from the group consisting of STPs, SCPs 
and SSPs. 

9. A system as in claim 1, further comprising a 
data model, which is in communication with at least some of the 
platforms,- wherein the data model includes code for providing 
the- state, attributes and behavior of telecommunications 
domain objects. 

10. A system as in claim 1, wherein at least one of 
the platforms includes at least one user interface. 

11. A telecommunications system, comprising: 

a plurality of platforms, each platform having a 
defined functional responsibility; 

a plurality of components selectively attachable to 
.the platforms, wherein the components of each platform operate 

together to perform various tasks within the functional 
• responsibility of the platform; and 

at least one network element in communication with 
one of the platforms to allow configuration information to be 
transmitted. from the platform to the network element. 

12. A method for providing telecommunications 
seirvices , comprising : 

providing a plurality of platforms, wherein each 
platform is assigned a functional responsibility; 
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5 selectively- placing at least one component into each 

6 of the platforms, wherein each component performs a task 

7 within the functional responsibility of the platform; 

8 processing telecommunications information relating 

9 to a service with the components; and 

10 transmitting at least some of the processed 

11 information to networks responsible for the delivery of 

12 telecommunications services. 

1 13, A method as in claim 12, wherein each platform 

2 provides common services to each of its components to perform 

3 the task. 

1 14. A method as in claim 12, wherein some of the 

2 components comprise application components, wherein one of the 

3 components comprises a service component, and further 

4 comprising determining with the service component the type of 

5 application components upon placement of the application 

6 components into a platform. 

1 15. A method as in claim 12, further comprising 

2 selectively placing a plurality of different components into 

3 each of the platforms, wherein the components in each platform 

4 cooperate together to perform various tasks within the 

5 functional responsibility of the platform. 

1 16. A method as in claim 15, wherein the functional 

2 responsibilities are selected from the group consisting of 

3 service management (customer facing) , service management 

4 (network facing) , network management, and network element 

5 management . 

1 17. A method as in claim 15, wherein the component 

2 is selected from the group of components consisting of order 

3 entry systems, order management systems, service provisioning 

4 ' management systems, inventory management systems, and work 

5 force administration systems. 
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18. A method as in claim 15, wherein the components 
are selected to provide a local number portability task, and 
wherein the transmitted information comprises call routing 
information which provisions the network elements. 

19. A method as in claim 15, f.urther comprising 
translating at least some of the telecommunications 
information from one of the platforms and transmitting the 
translated information to at least one other platform. 

20. A method as in claim 15, further comprising 
translating at least some of the telecommunications 
information and transmitting the translated information to 
another service provider telecommunications system. 

21-. A method as in claim 15, further comprising 
receiving telecommunications information from another service 
provider, translating the received information and 
transmitting the translated information to at least some of 
the platforms. 

22. A method as in claim 15, further comprising 
accessing -information from at least one of the components with 
a graphical user interface. 

23. A method as in claim 15, further comprising 
transmitting state, behavior and usage information relating to 
telecommunications domain objects ^.to at least one of the 
platforms to assist the components in performing a task. 

24. A method as in claim 23, wherein the state, 
behavior and usage information comprises network element 
requirements, facilities requirements and work force 
requirements needed to accomplish a task. 



25. A method- for providing telecommunications 
seirvices, comprising: 
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3 ordering a telecommunications service and entering 

4 the order into an order entry component interfaced with a 

5 service management (customer facing) platform; 

6 querying a data model through the service management 

7 (customer facing) platform to determine if the product, is 

8 available for order; 

9 transmitting information relating to the order to a 

10 service management (network facing) platform having an order 

1 1 management component ; ■ - 

12 querying the data. model through the service 

13 management (network facing) platform to determine the 

14 particular resources that are required to service the order; 

15 transmitting information relating to the order to a 

16 network management platform to determine if the particular 

17 resources are available to service the order; and 

18 transmitting information relating to the order to a 

19 network element management platform to service the order on a 

20 network element. 

1 26. An engine for use in a telecommunications 

2 system, comprising: 

3 a component which is adapted to selectively 

4 interface with a platform having a defined functional 

5 responsibility within the - telecommunications system, wherein 

6 the component, includes code to assist in performing a task 

7 within the functional responsibility of the platform, whereby 

8 configuration information may be transmitted from the platform 

9 to a network element . 

1 27. An engine as in claim 26, wherein the component 

2 is selected from the group of components consisting of network 

3 management systems, service order management systems, order 

4 entry systems, monitoring systems, billing systems, inventory 

5 systems, work force administration systems, rating systems, 

6 capacity planning systems, and network operations systems. 
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